Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

這系列文源自這幾年在團隊裡導入 AI Coding 之後，一路踩雷、修正、再踩雷的真實過程。把這些收斂出來的方法整理成文，也許對正在煩惱同樣問題的你會有些幫助。

就當作是一份邊做邊記的工程筆記吧！

本篇是 當 AI 加入團隊：打造可審查、可驗證、會自我改善的 AI 開發工作流 系列文的 EP08。

工程經驗通常在任務結束後才最清楚。

修完一個難纏的 bug，回頭看才會發現「早知道一開始就先查那份日誌」。

但這種頓悟，很容易就這樣被遺忘在收工的那一刻。

所以我們讓 AI 在完成一次有意義的工作後，自動跑一次「回顧」：
把這次任務整理成幾條可能有用的改善提案——也許是一個新的 skill、一則知識條目、一個 prompt 的改法，或是流程本身需要修正的地方。

.\scripts\start-session-retrospective.ps1 `
  -SessionTitle "某次裝置韌體更新後的異常排查" `
  -RepoPath "$env:USERPROFILE\source\product-repo" `
  -RelatedWorkflow "issue-fix-and-commit"

回顧跑完之後，手上該留下的是幾條提案，不是整段對話的備份。

這裡要特別強調一點：重點不是保存完整的對話紀錄。

而是從裡面挑出「下一次遇到類似情況也用得上」的那幾條學習，並且在寫下來之前，先把秘密、客戶資料、跟這次任務綁死的環境細節都去掉。

一個沒有真正被使用的最佳化，永遠停留在某個人的腦子裡；但一份被寫下來、送進審查流程的提案，才有機會變成下一位遇到同樣情境的人，少走的那一段冤枉路。

這加起來其實就一句話：
把這次任務裡能複用的經驗寫下來，但寫下來的是提案，不是立刻生效的規則。

提案寫出來了，但寫出來的東西就能直接變成團隊規則嗎？

當然不行——下一篇來談為什麼。